-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
v2.0 docs update #186
v2.0 docs update #186
Conversation
1e357f9
to
12832b5
Compare
12832b5
to
3b5c56b
Compare
@@ -52,15 +51,12 @@ SELECT | |||
id, | |||
category_code, | |||
category_code_system, | |||
component, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the fields removed here were not flattened - i'll swing back around on the required/must support fields on these.
__Important detail on FHIR arrays__: When we flatten a FHIR element that | ||
is specified as being potentially an array (like many instances of | ||
CodeableConcept, for example), we create a seperate table from that | ||
field. It can be joined back to the table it was extracted from by the | ||
id field present in both tables. | ||
|
||
However - in your study design, you will need to handle cases where | ||
multiple items may exist in these tables. It is common for multiple | ||
code systems to be used for a single record. | ||
|
||
As an example, the Condition resource has a base level CodeableConcept | ||
that _should_ contain a SNOMED code, but often has only an ICD9/10 code, | ||
or a EHR vendor specific code. We handle this case in two ways: | ||
- The __core__condition_codable_concepts_display__ table contains one | ||
record per resource, where we specify a priority order and take the | ||
first valid code we find, which is ok for cases where you aren't | ||
very concerned about a specific coding and are just looking to get | ||
an idea of what data you have | ||
- The __core__condition_codable_concepts_all__ table contains | ||
every code for every system found. This is useful when you are specifically | ||
looking for data associated with a given clinical coding system, but | ||
if you are not careful, you can cause a condition to be counted twice | ||
by not specifying a coding system when joining this table with the | ||
base condition table. | ||
|
||
Your approach to handling this is going to be dictated by the specific | ||
clinical context you're working with. In cases where we don't specify | ||
two table types for an array resource, you should assume that we are | ||
following the second pattern and account for that in your queries. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Explicitly calling out this large text block i just added about the denormalized tables.
To document your study strucuture, you can use the `generate-md` command | ||
to create markdown tables you can copy into your study docs. Note that, | ||
as of this writing, you'll need to supply a description for each field by | ||
hand. This output will be generated inside your study, in a file named | ||
`{study name}_generated.md`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also calling out the 'you need to define your own description, for now'
This PR adds documentation around some V2 features, and a generator for creating markdown tables.
Checklist
docs/
) needs to be updated